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L16: Entry 1 of 4 



File: PGPB 



Jun 1 3 , 



2002 



DOCUMENT-IDENTIFIER: US 20020071529 Al 

TITLE: Method and system for multimedia network based data acquisition, recording 
and distribution 



19. A method for managing intelligent, network-based, multi-media recording and 
distribution services for distributed business organizations via a wide-area public 
switched telecom network or a wireless network, said method comprising: 
establishing telecom links with a plurality of service access nodes in the public 
telecom network for accessing subscriber calls, containing both voice and data; 
providing at least one access administration module for defining PRN parameters 
that identify communications to be acquired; providing at least one acquisition 
module for processing content and call information directed through a transfer data 
network to at least one recording center; establishing at least one recording 
administration module for defining and. controlling recording, and all associated 
recording processing and storage policies, and retrieval/distribution services of 
said subscriber calls derived from the public network; and transferring 
retrieval/distribution- data through a retrieval/distribution data network to at 
least one workstation for providing said retrieval/distribution service. 

40. A system for managing intelligent, network-based, multi-media recording and 
playback services to distributed business organizations via a wide-area public 
telecom network, said system comprising: a plurality of service access nodes 
connected to telecom links in the public telecom network; at least one access 
administration module for defining PRN parameters that identify communications to 
be acquired; at least one acquisition management module for processing content and 
call information directed through a transfer data network to at least one recording 
center; at least one recording administration module for processing recording and 
playback information derived from said public network; and at least one playback 
workstation to receive playback data for playback service. 
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File: USPT 



Jul 8, 1997 



DOCUMENT-IDENTIFIER: US 5646945 A 

** See image for Certificate of Correction ** 

TITLE: Telecommunications system and telecommunications terminal equipment 
Detailed Description Text (27) : 

The described configuration example contains all the essential features of the 
invention. Beyond that, numerous other configuration examples can be envisioned, 
which are perhaps targeted for highly integrated telecommunications terminals (e.g. 
multi-media terminals) or for complex telecommunications networks with IN functions 
(IN: intelligent network, such as UMTS: Universal Mobile Telecommunication System). 
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LIS: Entry 1 of 1 



File: USPT 



Jul 9, 1996 



DOCUMENT-IDENTIFIER: US 5535263 A 

TITLE: Method for recording subscriber specific messages in an advanced intelligent 
network 



CLAIMS : 

18. The method of claim 17, further comprising: 

generating a NCA.sub. — Request message at said AIN SCP for receipt by said IP, 
said NCA.sub. — Request message requesting the media type; and 

generating a NCA.sub. 13 Response message at said IP for receipt by said AIN SCP, 
said NCA.sub. 13 Response message indicating the type of media selected. 
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Lll: Entry 1 of 1 File: USPT Jul 9, 1996 



DOCUMENT-IDENTIFIER: US 5535263 A 

TITLE: Method for recording subscriber specific messages in an advanced intelligent 
network 



Abstract Text (1) : 

A method for recording subscriber specific messages in a telephone call for use in 
telephone services, particularly, for use in cooperation with an AIN Service 
Switching Point (SSP) , an AIN Service Control Point (SCP) and an Intelligent 
Peripheral (IP) . A Calllnf oToResource message is generated at the AIN SCP for 
receipt by the SSP and the IP. The message instructs the SPP to establish a 
connection to the IP and further instructs the IP to record a subscriber message. 
The SSP generates a PRIFACILITY message which is directed for receipt by the IP and 
instructs the same to play an announcement and begin recording. Thereafter, an 
announcement is played at the IP which instructs the subscriber to begin speaking. 
The subscriber's message is recorded and a release message is generated at the SSP 
for receipt by the IP. The release message instructs the IP to tear down the call. 
A ResourceClear message is thereafter generated at the SSP for receipt by the SCP. 
The ResourceClear message indicates the status of the recording and an ID 
corresponding to the announcement to be used by the SCP in other services. A 
Disconnect message is thereafter generated at the SCP for receipt by the SSP. The 
Disconnect message instructs the SSP to tear down the call. 

Application Filing Date (1) : 
19941013 

Brief Summary Text (2) : 

The present invention relates generally to Advanced Intelligent Networks (AIN ) . 
More particularly, the invention relates to a method for recording subscriber 
specific messages in a telephone call for use in telephone services. 

Brief Summary Text (4) : 

Telephone service providers presently have available numerous telephone services 
which may be offered to subscribers. Many of these services require greetings or 
other types of audible announcements to be recorded and played. As those skilled in 
the art will recognize, it is highly desirable to have these messages recorded in 
the voice of the telephone subscriber. However, the current state of available 
technology has heretofore prohibited such an approach. 

Brief Summary Text (5) : 

As an example, consider an AIN "Do not Disturb" service which may be used to advise 
calling parties that the called party is presently unavailable and to try again 
later. While it would desirable to have this message provided in the voice of the 
called party, current technology requires such recordings to be physically "burned" 
into the Read Only Memory (ROM) of the corresponding central office switch of each 
subscriber. As readily seen, this is clearly an unmanageable task which becomes 
further complicated if the user desires to change his or her message or telephone 
at a later date. 

Brief Summary Text (9) : 



http://westbra:9000toi^ 9/27/04 



Record Display Form 



Page 2 of 7 



It 'is a further object of the present invention to provide a method as above which 
Is specifically directed for use in cooperation with an AIN Service Switching Point 
(SSP) , the Service Switching Point connected to each of a subscriber, an AIN 
Service Control Point (SCP), and an Intelligent Peripheral (IP). 

Brief Summary Text (11) : 

The method is directed for use in cooperation with an AIN Service Switching Point 
(SSP) which is connected to each of a subscriber, an AIN SCP, and an Intelligent 
Peripheral, as indicated above. The method comprises the steps of generating a 
"CalllnfoToResource" message at the AIN SCP for receipt by the SSP and the IP. The 
Calllnf oToResource message instructs the SSP to establish a connection to the IP 
and further instructs the IP to record a subscriber specific message. 

Brief Summary Text (12) : 

The method further includes the generation of a PRI FACILITY message at the SSP for 
receipt by the IP. The PRI FACILITY message instructs the IP to play an announcement 
and begin recording. Thereafter, the announcement is played at the IP which 
instructs the subscriber to begin speaking. When the subscriber has completed his 
or her message, recording is stopped and a RELEASE message is generated at the SSP 
for receipt by the IP. The release message instructs the IP to tear down the call. 
Thereafter, a ResourceClear message is generated at the SSP for receipt by the SCP. 
The ResourceClear message indicates the status of the recording and an ID 
corresponding to the announcement to be used by the SCP and other services. 

Brief Summary Text (14) : 

In one preferred embodiment of the invention, the AIN SCP is connected to the AIN 
SSP through Common Channel Signaling (CCS) and communicates with the SSP with AIN 
0.0 or later TCAP messaging. The subscriber is further connected to the SSP with 
normal lines such as Basic Rate Interface (BRI) , Plain Old Telephone Service 
(POTS), etc. The SSP is further connected to the IP with trunks such as Primary 
Rate Interface (PRI), Tl, etc. or lines such as Basic Rate . Interface (BRI), Plain 
Old Telephone Service (POTS), etc. In this preferred embodiment, the signaling 
between the SCP and the IP also takes place using an AIN 0.2 interface. 

Brief Summary Text (16) ; 

In yet another alternative embodiment, the method of the present invention may be 
operative with multiple media . In such a case, the incoming trunks/lines 
terminating at the IP may be mixed in use and the method further requires the 
generation of an NCA.sub. — Request message at the AIN SCP for receipt by the IP. 
The NCA.sub. — Request message requests the media type . Still further, an 
NCA.sub. 13 Response message will be generated at the IP for receipt by the SCP. The 
NCA.sub. 13 Response message indicates the type of media selected. 

Drawing Description Text (3) : 

FIG. 1 is a schematic network diagram of the AIN infrastructure required for use 
with the present invention; 

Drawing Description Text (5) : 

FIG. 3 is a schematic diagram of the message flows of the AIN service logic 
contained on the SCP in accordance with the present invention; and 

Detailed Description Text (2) : 

Referring to FIG. 1, there is shown a network diagram of the Advanced Intelligent 
Network (AIN ) infrastructure 10 required for use with the present invention. System 
10 includes an AIN end office with AIN 0.0 or later software such as AIN Service 
Switching Point (SSP) 12. As those skilled in the art will recognize, in AIN 
architecture, Service Switching Points are generally nodes (usually the 
subscriber's local switch/central office switch) that recognize the "triggers" used 
when a subscriber invokes an Intelligent Network service and then communicates with 
a Service Control Point (SCP) to operate the service. AIN Service Control Points 
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are nodes which contain the service logic and associated data support to execute 
the required customer services. AIN Service Switching Points are typically 
connected to AIN Service Control Points via signaling links and packet switches 
such as AIN Service Transfer Points (STPs) . 

Detailed Description Text ( 3) : 

Referring still to FIG. 1 of the drawings, SSP 12 is connected with the Customer 
Premises Equipment (CPE) device 14 of the subscriber with normal lines such as 
Plain Old Telephone Service (POTS), Basic Rate Interface (BRI), etc. System 10 
further includes an AIN Service Control Point (SCP) 16 which is connected to SSP 12 
through Common Channel Signaling (CCS) such as CCS No. 7 (SS7) and is shown in one 
preferred embodiment of FIG . 1, connected through a Service Transfer Point (STP) 
18. 

Detailed Description Text (4) : 

Designed to be used primarily in high speed digital networks, Common Channel 
Signaling System No. 7 { SS7 ) is capable of controlling low speed analog facilities 
as well. SS7 generally operates at 64 KbPS and can support variable message links 
up to 2,176 bits {272 octets) of information per message. In keeping with the 
invention, SCP 16 communicates with Intelligent Peripheral (IP) 20 using either an 
AIN 0.2 IP interface or a direct data interface. 



Detailed Description Text (5) : 

As those skilled in the art will further recognize, an AIN 0.2 IP interface is an 
interworking between Transaction Capability Application Part (TCAP) protocol and 
Integrated Services Digital Network (ISDN) Q.931 protocol, where the SCP 16 
communicates to the IP 20 using TCAP, and the IP 20 communicates to the SSP 12 
using Q.931. The SSP 12 interworks TCAP and Q.931. 

Detailed Description Text (6): 

In keeping with the invention, IP 20, which contains recording equipment for voice, 
fax, and other media, is connected with SSP 12 using trunks (TRI, Tl, etc.) or 
lines (POTS, BRI). IP 20 can also be remotely located. 

Detailed Description Text (7) : 

Alternatively, the signaling between SCP 16 and IP 20 may take place using a direct 
data interface. This is a direct connection, or connection through a data network, 
between the SCP 16 and the IP 20. As those skilled in the art will recognize, the 
higher layer protocol is very similar to that in the AIN 0.2 IP interface, except 
that Signaling System No. 7 (SS7) is not used. The underlying protocol would most 
likely be Ethernet, Fiber Distributed Data Interface (FDDI), Switched Multi-megabit 
Data Service (SMDS) , etc. 

Detailed Description Text ( 8) : 

The capability to record and use messages is controlled through service logic 
located in the AIN SCP 16. FIGS. 2-3 show the call . flows between SSP 12, SCP 16, 
and IP 20 which are used to record voice for use in an announcement in accordance 
with the present invention. In these call flows, it is assumed for illustration 
purposes that an AIN 0.2 IP interface is being used for a local IP. 

Detailed Description Text (9) : 

FIG. 2 provides a schematic diagram of the call flows resulting from a subscriber 
calling a specific "administration" telephone number. Subsequent to these call 
flows, the AIN service logic on the SCP is activated with the resulting call flows 
which are shown in FIG. 3. Referring to FIG. 2, the subscriber must first dial an 
administration number 22 that is used to record an announcement . This 
administration number on SSP 12 is provisioned with an AIN trigger. In the example 
shown, it is a termination attempt trigger 24. In keeping with the invention, 
however, it is recognized that other triggers could be used. Through the trigger, 
the SSP 12 detects that the administration number has been dialed and launches an 
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AIN query to the SCP 16. Thereafter, the AIN service logic on the SCP is invoked. 
Since the user is requesting to record an announcement, SCP 16 responds with a 
SendToResource message 26. SSP 12 will then send a PRI SETUP message 28 to the IP 
20, instructing it, among other things, to play an announcement instructing the 
subscriber to enter his or her Personal Identification Number (PIN) . 

Detailed Description Text (11) : 

With reference now to FIG. 3 of the drawings, it is assumed that the PIN was 
entered correctly. The AIN service logic of the SCP to which the present invention 
is directed may thus be described. 

Detailed Description Text (12) : 

As shown, the SCP 16 sends a Calllnf oToResource message 38 to SSP 12. The 

Calllnf oToResource message 38 instructs the SSP 12 to establish a connection to the 

IP 20, and for the IP 20 to record a message. The AIN Calllnf oToResource message is 

modified. Specifically, the resource-type parameter is expanded to include the 

following: 

Detailed Description Text (13) : 

1001 Play Announcement and Record Message 

Detailed Description Text (14) : 

1002 Play Announcement, Record Message and Collect Digits 
Detailed Description Text (43) : 

Thereafter, SSP 12 sends a PRIFACILITY message 40 to IP 20. This message instructs 
the IP 20 to play an announcement and begin recording, as defined above. The IP 20 
thereafter plays an announcement 42 instructing the subscriber to begin speaking. 
The subscriber begins speaking 44 and, when finished, either lets the IP 20 time 
out or enters a digit, i.e. a Dual Tone Multi-Frequency (DTMF) digit to complete 
recording. Next, SSP 12 returns a RELEASE message 46 to the IP 20, instructing it 
to tear down the call. SSP 12 thereafter returns a ResourceClear message 48 to the 
SCP 16, indicating the status of the recording and the announcement ID to be used 
later in another service. It should be noted that in keeping with the invention, 
the CalllnfoFromResource message may also be used if additional recordings are 
desired in the same session. This capability requires changes to the ResourceClear 
(and CalllnfoFromResource) message as follows. 

Detailed Description Text (47) : 

After performing the above steps, the SCP 14 would have an Announcement ID to be 
used in other services. Finally, SCP 16 returns a Disconnect message 50 to SSP 12, 
instructing it to tear down the call. 

Detailed Description Text (48): 

As referenced above, the present invention is also operable with respect to 
multiple media . In such a case, two preferred methods have been considered by 
applicant in which the IP 20 and SCP 16 may identify a specific media : 

Detailed Description Text (49): 

(1) Incoming trunks/lines terminating at the IP 20 can be dedicated to specific 
media . That is, certain trunk groups may be dedicated to voice messaging, while 
other trunk groups may be dedicated to FAX messaging, etc. In such case, the 
service logic on SCP 16 would determine the media type by its trunk identification 

(ID) ; 

Detailed Description Text (50) : 

(2) Alternatively, incoming trunks/lines terminating at the IP 20 can be mixed in 
use. That is, a specific trunk/line can be used for voice and fax. "Off the shelf" 
equipment exists today that can handle both voice and fax. In such a case, the 
messaging between IP 20 and SCP 16 needs to identify a media type . Rather than 
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modify existing messages, this will be accomplished with "non-call associated 
signaling". That is, SCP 16 can send a message to IP 20 at any time, regardless of 
a call . 

Detailed Description Text (51) : 

In order to do this, the EnvelopContent parameter of the NCA.sub. — Request message 
will be defined (see GR-1129 Core Advanced Intelligent Network (AIN ) Switch- 
Intelligent Peripheral Interface (IPI) generic requirements, Bellcore Issue 1, 
November 1993 for Non-call Associated signaling message definitions) . In operation, 
SCP 16 would send an NCA.sub. — Request message to the IP 20, requesting the media 
type. IP 20 would then respond with an NCA.sub. — Response, indicating voice, FAX, 
etc. Specifically, the EnvelopContent for the NCA.sub. — Request message will be 
encoded as follows: 

Detailed Description Text (52) : 

First Octet Bit A-H: 1 for query media type message. 
Detailed Description Text (54) : 

First Octet Bit A-H : media type (0 for voice, 1 for fax, 2 for video, etc.) 
Detailed Description Text (60) : 

With reference to FIG. 4 of the drawings, the above method steps may be further 
summarized. As indicated, the method is directed for use in cooperation with an AIN 
Service Switching Point (SSP) which is connected to each of a subscriber, an AIN 
Service Control Point (SCP) and an Intelligent Peripheral (IP). The method includes 
generating 52 a Calllnf oToResource message at the AIN SCP for receipt by the SSP 
and the IP. The Calllnf oToResource message instructs the SSP to establish a 
connection to the IP and further instructs the IP to record a subscriber message. 
Thereafter, a PRIFACILITY message is generated 54 at the SSP for receipt by the IP. 
The PRIFACILITY message instructs the IP to play an announcement and begin 
recording. 

Detailed Description Text (61) : 

An announcement is thereafter played 56 at the IP instructing the subscriber to 
begin speaking. Following recordal 58 of the subscriber's message, a RELEASE 
message is generated 60 at the SSP for receipt by the IP. The RELEASE message 
instructs the IP to tear down the call. Thereafter, a ResourceClear message is 
generated 62 at the SSP for receipt by the SCP. The ResourceClear message indicates 
the status of the recording and an ID corresponding to the announcement to be used 
by the SCP in other services. Finally, a DISCONNECT message is generated 64 at the 
SCP for receipt by the SSP. The disconnect message instructs the SSP to tear down 
the call. 

Other Reference Publication (1) : 

"The Intelligent Network Concept", Jean S. Doyle et al., IEEE Transactions on 
Communications, vol. 36, No. 12, Dec. 1988, pp. 1296-1301. 

CLAIMS : 

1. For use in cooperation with an Advanced Intelligent Network (AIN ) Service 
Switching Point (SSP), said SSP connected to each of a subscriber, an AIN Service 
Control Point (SCP) and an Intelligent Peripheral (IP), a method for recording a 
subscriber specific message in a telephone call for use in telephone services, 
comprising : 

generating a Calllnf oToResource message at said SCP for receipt by said SSP and 
said IP, said Calllnf oToResource message instructing said SSP to establish a 
connection to said IP and further instructing said IP to record a subscriber 
message; 
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generating a PRIFACILITY message at said SSP for receipt by said IP, said 
PRI FACILITY message instructing said IP to play an announcement and begin 
recordings- 
playing an announcement at said IP instructing said subscriber to begin speaking; 
recording said subscriber's messages- 
generating a RELEASE message at said SSP for receipt by said IP, said release 
message instructing said IP to tear down the call; 

generating a ResourceClear message at said SSP for receipt by said SCP, said 
ResourceClear message indicating the status of the recording and an identification 
corresponding to said announcement to be used by said SCP in other services; and 

generating a Disconnect message at said SCP for receipt by said SSP, said 
Disconnect message instructing said SSP to tear down the call. 

2. The method of claim 1, wherein said AIN SCP is connected to said AIN SSP through 
Common Channel Signaling (CCS) and communicates with said SSP with AIN 0.0 or later 
Transaction Capability Application Part (TCAP) messaging. 

3. The method of claim 1, wherein said subscriber is connected to said AIN SSP with 
lines . 

4. The method of claim 1, wherein said subscriber is connected to said AIN SSP with 
Basic Rate Interface (BRI) lines. 

5. The method of claim 1, wherein said subscriber is connected to said AIN SSP with 
Plain Old Telephone Service (POTS) lines. 

6. The method of claim 1, wherein said AIN SSP is connected to said IP with trunks. 



7. The method of claim 1, wherein said AIN SSP is connected to said IP with Primary 
Rate Interface (PRI) trunks. 

8. The method of claim 1, wherein said AIN SSP is connected to said IP with Tl 
trunks . 

9. The method of claim 1, wherein said AIN SSP is connected to said IP with lines. 

10. The method of claim 1, wherein said AIN SSP is connected to said IP with Plain 
Old Telephone Service (POTS) lines. 

11. The method of claim 1, wherein said AIN SSP is connected to said IP with Basic 
Rate Interface (BRI) lines. 

12. The method of claim 1, wherein the signaling between said AIN SCP and said IP 
takes place using an AIN 0.2 interface. 

13. The method of claim 1, wherein the signaling between said AIN SCP and said IP 
takes place using a direct data interface. 

15. The method of claim 1, wherein said AIN SCP and .said IP are operative with 
multiple media . 

16. The method of claim 1 wherein said AIN SCP includes ' service logic operative to 
determine media type by trunk identification. 
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17. The method of claim 15, wherein said AIN SSP is connected to said IP with 
trunks and lines. 

18. The method of claim 17, further comprising: 

generating a NCA.sub. — Request message at said AIN SCP for receipt by said IP, 
said NCA.sub. — Request message requesting the media type ; and 

generating a NCA.sub. 13 Response message at said IP for receipt by, said AIN SCP, 
said NCA.sub. 13 Response message indicating the type of media selected. 

Previous Doc Next Doc Go to Doc# 
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L14: Entry 1 of 22 



File: PGPB 



Oct 3, 2002 



DOCUMENT-IDENTIFIER: US 20020141381 Al 

TITLE: Session initiation protocol based advanced intelligent network/intelligent 
network messaging 



Abstract Paragraph : 

A method and system enables distributed transaction oriented telephony 
functionality for telephony services in a broadband packet network. Exemplary 
distributed transaction oriented telephony functionality includes Intelligent 
Network (IN) and Advanced Intelligent Network (AIN ) functionality accessed through 
the legacy Common Channel Signaling (CCS) network using transaction-based messaging 
protocols, such as Intelligent Network Application Part (INAP) and/or Transaction 
Capability Application Part (TCAP) protocols. A functional content of a transaction 
message, such as a TCAP message, is encapsulated in a Protocol Data Unit (PDU) of 
the broadband packet network. The PDU is forwarded through the broadband packet 
network to a second network element. The functionality is then invoked using the 
encapsulated transaction message functional content. In preferred embodiments the 
PDU is a Session Initiation Protocol (SIP) envelope, into which TCAP message 
functional content can be mapped. 

Application Filing Date : 
20001130 

Summary of Invention Paragraph : 

[0003] The present invention relates to intelligent network /advanced intelligent 
network (IN /AIN ) services, and, in particular, to a method of enabling IN /AIN 
functionality for telephony services deployed in a broadband packet network. 

Summary of Invention Paragraph : 

[0004] Modern telephony services deployed in the Public Switched Telephone Network 
(PSTN) commonly rely on distributed transaction oriented telephony functionality, 
such as, for example Intelligent Network and/or Advanced Intelligent Network 
(IN /AIN ) functionality in order to deliver sophisticated call control services to 
subscribers. Typically, this distributed functionality involves various network 
elements (e.g. Service Control Points (SCP's), Intelligent Peripherals (IPe f s) and 
Interactive Voice Response (IVR) servers) and transaction-based protocols (such as 
Intelligent Network Application Part (INAP), and Transaction Capability-Application 
Part (TCAP)) deployed in the Common Channel Signaling (CCS) network. INAP and TCAP 
operate over conventional Signaling System 7 (SS7) infrastructure, and supplements 
legacy Integrated Services Digital Network-User Part (ISUP) signaling by providing 
a query/response protocol for accessing routing information and telephony services 
provided by IN /AIN capable network elements within the CCS network. 

Summary of Invention Paragraph : 

[0007] In order to address issues of scalability within the PSTN, various efforts 
have been made to deploy telephony services in a broadband packet network such as 
an internet protocol (IP) network. Various protocols have been proposed to enable 
this functionality, including various Voice over IP (VoIP) protocols for carrying 
bearer traffic, as well as session set-up and routing protocols (such as Multi- 
protocol Label Switched Path (MPLS) and Session Initiation Protocol (SIP)) for 
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establishing communications sessions and for routing the bearer traffic through the 
network. In general, it is also possible to deploy resources in a broadband packet 
network that enable services similar to those provided by the legacy CCS network. 
However, in order to establish telephone connections between points in the PSTN and 
a packet network, interaction between resources of the broadband packet and CCS 
networks is essential. One method of accomplishing this has been proposed by V. 
Gurbani in an Internet Engineering Task Force (IETF) draft entitled "Accessing IN 
services from SIP networks". FIG. 1 is a block diagram illustrating the system of 
Gurbani for enabling IN /AIN functionality for telephony services deployed in a SIP 
network 2. As shown in FIG. 1, Gurbani teaches an IN state machine 4 overplayed on 
the conventional SIP state machine 6 within a SIP server 8 of the SIP network 2. 
The IN state machine 4 operates to generate conventional TCAP messages reflecting 
the state of the SIP state machine 6, and forwards these messages though the legacy 
CCS network 10 to an IN /AIN capable device/ 12 (e.g. an SCP and/or an IPe) . TCAP 
messages (e.g. response messages) are received over the CCS network 10 by the IN 
state machine 4 and passed to the SIP state machine 6 to control call setup through 
the SIP network 2. 

Summary of Invention Paragraph : 

[0008] Thus, in the system of Gurbani, the IN state machine 4. operates as an 
interface between the SIP network 2 and the conventional CCS network 10, which 
enables a SIP server 8 to emulate a Service Switch Point (SSP) of the PSTN for the 
purposes of accessing IN /AIN functionality. However, this system suffers from the 
limitation that it increases the amount of TCAP traffic in the CCS network 10, and 
thus increases the risk of signaling port exhaustion in the CCS network element 12. 
This risk increases as the amount of telephony traffic in the SIP network 2 
increases. 

Summary of Invention Paragraph : 

[0014] The broadband packet network comprises any one or more of: an Asynchronous 
Transfer Mode (ATM) network; an internet Protocol (IP) network; a Frame Relay (FR) 
network; and an Integrated Services Digital Network (ISDN) . In preferred 
embodiments of the invention, the broadband packet network comprises an IP Network, 
and the PDU comprises a Session Initiation Protocol (SIP) message envelope. In such 
cases, the functional content of an IN /AIN message may be inserted into a 
Multipurpose Internet Mail Extension (MIME) part of the SIP envelope. 

Summary of Invention Paragraph : 

[0015] Each network element may comprise a media gateway controller adapted to 
enable telephony signal traffic through the broadband packet network, or an 
application server adapted to invoke IN /AIN functionality using IN /AIN functional 
content. An application server may be either: a CCS network element adapted to send 
and receive PDU ! s of the broadband packet network; or a network element of the 
broadband packet network. 

Summary of Invention Paragraph : 

[0017] Alternatively, encapsulation of the functional content of the transaction 
message may comprise mapping a transaction message onto the PDU . In some 
embodiments, the transaction message is a Transaction Capability-Application part 

(TCAP) message. In such cases, a TCAP message type is mapped onto a respective 
message type of the PDU. The TCAP message type may comprise any of: query; 
response; conversation; unidirectional and abort. In other embodiments, the 
transaction message is an Intelligent Network -Application part (INAP) message. In 
such cases, an INAP message type is mapped onto a respective message type of the 
PDU. The INAP message type may comprise any of: begin; end; continue; 
unidirectional and abort. 

Summary of Invention Paragraph : 

[0020] An advantage of the present invention is that conventional TCAP message 
functional content can be transported across the broadband packet network to an 
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Application Server to invoke IN /AIN functionality, without utilizing legacy CCS 
network infrastructure. Consequently, IN /AIN functionality can be invoked in 
respect of telephony services deployed in the broadband packet network, without 
contributing to signaling port exhaustion in the CCS network. 

Brief Description of Drawings Paragraph : 

[0022] FIG. 1 is a block diagram schematically illustrating operations of a prior 
art system for accessing IN /AIN functionality for telephony services in a broadband 
packet network; 

Brief Description of Drawings Paragraph : 

[0023] FIG. 2 is a block diagram schematically illustrating operations of a system 
for accessing IN /AIN functionality for telephony services in a broadband packet 
network, in accordance with an embodiment of the present invention; 

Brief Description of Drawings Paragraph : 

[0026] FIG. 4a is a message flow diagram showing principle messages exchanged in an 
AIN send-to-resource transaction in accordance with the prior art; 

Brief Description of Drawings Paragraph : 

[0027] FIG. 4b is a message flow diagram showing principle messages exchanged in 
the AIN send-to-resource transaction of FIG. 4a utilizing TCAP encapsulated within 
SIP in accordance with an embodiment of the present invention; 

Detail Description Paragraph : 

[0032] The present invention provides a method and apparatus for enabling 
Intelligent Network /Advanced Intelligent Network (IN /AIN ) functionality for 
telephony services deployed in a broadband packet network. FIG. 2 is a block 
diagram illustrating exemplary elements of a network 14 in which the present 
invention may be deployed. 

Detail Description Paragraph : 

[0033] As shown in FIG. 2, telephony services can be deployed within a broadband 
packet network 14 in a generally conventional manner. The broadband packet network 
14 can be formed of one or more federated packet networks (e.g. Internet Protocol 

(IP), asynchronous transfer mode (ATM), frame relay (FR) and Integrated Services 
Digital network (ISDN)) with appropriate format adaptation at network boundaries. 
Communications sessions can be set up across the broadband packet network 14, e.g. 
between media gateway controllers (MGCs) 16a, 16b using any known session control 
protocol, such as, for example, Session Initiation Protocol (SIP) , which may 
encapsulate legacy Integrated Services Digital Network-User Part (ISUP) messages to 
enable connections to be set up across the Public Switched Telephone Network (PSTN) 

(not shown) . IN /AIN functionality is provided by an application server (AS) 18, 
which may be provided as one or more legacy elements of the CCS network, such as, 
for example, Service Control Points (SCP's), Intelligent Peripherals (IPe's), and 
Interactive Voice Response (IVR) servers suitably adapted to enable signaling 
through the broadband packet network. Alternatively, the AS 18 may be provided as a 
server deployed in the broadband packet network 14. In the embodiment illustrated 
in FIG. 2, a single AS 18 is provided for invoking IN /AIN functionality. It will be 
understood that IN /AIN functionality will normally be provided by two or more 
devices, working alone or in combination. For ease of description of the present 
invention, a simplified network topology is presented, in which the IN /AIN 
functionality is enabled by interaction between a single MGC 16a of the broadband 
packet network and a single AS 18. It will be recognized, however, that the present 
invention is not limited to this simplified embodiment. 

Detail Description Paragraph : 

[0034]. The present invention operates to enable Intelligent Network Application 
Part (INAP) and/or Transaction Capability-Application Part (TCAP) query/ response 
transactions between MGCs 16 and application servers 18, bypassing the CCS network 
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infrastructure for message transport. This operation enables IN /AIN functionality 
for telephony services deployed in the broadband packet network 14, without 
increasing the risk of port exhaustion in CCS network elements Thus in accordance 
with the present invention, at least the functional content of each INAP and/or 
TCAP message is encapsulated within a PDU of the broadband packet network, which is 
then used for message transport. In embodiments in which the AS 18 is provided by 
legacy CCS network elements (e.g. SCP's and IPe ! s), a logical connection between 
the broadband packet network 14 and the AS 18, in order to facilitate transport of 
TCAP-encapsulating PDU ! s, can be established using existing IP, FR or ISDN ports of 
the AS 18, which are commonly used for network management traffic. Alternatively, 
the AS 18 can be provisioned with new IP ports, in addition to and/or in place of 
existing SS7 ports. By virtue of the flexibility and scalability afforded by IP, it 
is typically easier and less expensive to add IP ports to an existing SCP, IVR, or 
IPe than it is to add equivalent SS7 ports. 

Detail Description Paragraph : 

[0043] FIG. 4a shows principle steps of a "send to resource" conversation according 
to the prior art. As shown in FIG. 4a, an SSP forwards a TCAP-Query with Permission 

(QwP) to an SCP {at step S12) , which responds by returning a TCAP-Response (send to 
resource) to the SSP (step S14) . Based on the content of the TCAP-Response message, 
the SSP sets up a connection to an Intelligent Peripheral (IPe) (step S16) , which 
can then perform various functions, such as playing an announcement (step S18), 
and/or collecting dialed digits (step S20) . The IPe then forwards a Facility 
message (step S22) containing the results of its processing (e.g. dialed digits) to 
the SSP, which in turn forwards this data to the SCP in a TCAP-CwP (Call 
Information From Resource (CIFR) ) message to the SCP (step S24) . The SCP returns a 
TCAP-CwP (Call Information To Resource (CITR) ) message to the SSP (step S26) , which 
in turn forwards a Facility message containing the CITR information to the 
Intelligent Peripheral (step S28) . The Intelligent Peripheral then sends a Release 
message to the SSP (step S30) to release the connection between the SSP and the 
IPe. Upon receipt of the Release message, the SSP sends a TCAP-CwP message 
indicating that the resource is clear to the SCP (step S32), which returns a TCAP- 
Response message to the SSP (step S34) . As described above, the messages exchanged 
between the SCP and the SSP are TCAP messages. Conversely, messages exchanged 
between the SSP and the intelligent peripheral would normally be Private Rate 
Interface (PRI) protocol messages, conveyed over an Integrated Services Digital 
Network (ISDN) or ethernet link. 

Detail Description Paragraph : 

[0044] FIG. 4b illustrates the equivalent "send to resource" transaction using SIP 
encapsulating TCAP in accordance with the present invention'. As shown in FIG. 4b, 
an MGC 16 forwards a SIP-Invite message encapsulating the content of the TCAP-QwP 
message to the AS 18 (at step S36) , which responds by returning first a SIP-Ack 
(step S38) and then a SIP-182 Queued message encapsulating the content of a TCAP 
"send to resource" message to the MGC 16 (step S40) . Based on the content of the 
SIP-182 Queued message, the MGC 16 sets up a connection to an Intelligent 
Peripheral (Ipe) (step S42), which then performs various functions, such as playing 
an announcement (step S44) and/or collecting dialed digits (step S46) . The 
Intelligent Peripheral then forwards a Facility message containing the results of 
its processing (e.g. dialed digits) to the MGC 16 (step S48), which in turn 
forwards this data to the AS 18 in a SIP-182 Queued message (step S50) . The AS 18 
returns a SIP-182 Queued message containing Circuit Information To Resource (CITR) 
information to the MGC 16 (step S52), which in turn forwards a Facility message 
containing the CITR information to the Intelligent Peripheral (step S54) . The 
Intelligent Peripheral then sends a Release message to the MGC 16 (step S56) to 
release the connection between the MGC 16 and the IPe. Upon receipt of the Release 
message, the MGC 16 sends a SIP-182 Queued message indicating that the resource is 
clear to the AS 18 (step S58), which returns a SIP-200 OK message to the MGC 16 
(step S60) . As described above in respect of FIG. 4a, the signals between the MGC 
16 and the intelligent peripheral would normally be in Private Rate Interface (PRI) 
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messages, and may be conveyed over an Integrated Services Digital Network (ISDN) or 
ethernet link. 

Detail Description Paragraph : 

[0073] As is known in the art, MIME was originally designed to attach files to 
email messages, but can be readily adapted for use in other transport systems. For 
the purposes of the present invention, the MIME part 24 is used to attach the TCAP 
binary message part 28 to the end of the SIP/SDP combination. MIME multipart 
payloads enable a SIP envelope 20 to carry any PSTN/CCS signaling information 
required to invoke IN /AIN functionality. The multipart body can consist of any 
combination of: SDP payload; TCAP payload; and/or any number of MIME types. 

Detail Description Paragraph : 

[0084] The SIP message format requires the first line to be a 'Request' line, 
followed by a series of 'Header' lines, a <CRLF> separator, and, lastly, the 
message body. In the present example, the SDP Part 26 and MIME payload 28 are 
separated by a boundary parameter which, for this example, has the value of 
"unique-boundary-l" . 

Detail Description Table CWU : 

4TABLE 4 Field Description Example values v Version: protocol version number o 
Origin: owner or o=<username><session creator and session id><version> <network 
identifier typexaddress type><address> The value of this <username> is preferably 
the field must uniquely Calling Party from the SCCP identify the session global 
title, s Session Name: A text description m Media Description: m=<media> <port> 
<transport> Name and Transport <fmt list> address <media> may be any of "audio", 
"video", "application", "data" or "control" c Connection Data ^IN S (Internet) 
followed by the '1P4 S (identifying the This is an optional IP version 4 method of 
IP field address ID) followed by the connection IP address. Other variations exist, 
including TTL information for multicast addresses, e, p Email Address and This 
field may be used to Phone Number reflect the Calling Party e=<email address> 
address from the SCCP global p=<phone number> title address. These fields specify 
contact information of the person responsible for the Conference. This may not Be 
the initiator of the session. These are an optional field 

CLAIMS : 

2. A method as claimed in claim 1, wherein the distributed transaction oriented 
telephony functionality comprises intelligent network /advanced intelligent network 
(IN /AIN ) functionality. 

5. A method as claimed in claim 1, wherein the first network element comprises a 
media gateway controller adapted to enable telephony signal traffic through the 
broadband packet network. 

9. A method as claimed in claim 8, wherein the transaction message comprises either 
one of a Transaction Capabilities Application Part (TCAP) message and an 
Intelligent Network Application Part (INAP) message. 

14. A method as claimed in claim 10, wherein the transaction message comprises an 
Intelligent Network -Application Part (INAP) message. 

26. A system as claimed in claim 25, wherein the distributed transaction oriented 
telephony functionality comprises intelligent network /advanced intelligent network 
(IN /AIN ) functionality. 

29. A system as claimed in claim 25, wherein the first network element comprises a 
media gateway controller adapted to enable telephony signal traffic through the 
broadband packet network. 
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33. A method as claimed in claim 32, wherein the transaction message comprises 
either one of a Transaction Capabilities Application Part (TCAP) message and an 
Intelligent Network Application Part (INAP) message. 

38. A system as claimed in claim 34, wherein the transaction message comprises an 
Intelligent Network -Application Part (INAP) message. 

50. A node as claimed in claim 49, wherein the distributed transaction oriented 
telephony functionality comprises intelligent network /advanced intelligent network 
(IN /AIN ) functionality. 

53. A node as claimed in claim 49, wherein the node comprises either one of: a) a 
media gateway controller adapted to enable telephony signal traffic through the 
broadband packet network; and b) an application server adapted to invoke IN /AIN 
functionality using TCAP functional content. 

56. A node as claimed in claim 55, wherein the transaction message comprises either 
one of a Transaction Capabilities Application Part (TCAP) message and an 
Intelligent Network Application Part (INAP) message. 

61. A node as claimed in claim 57, wherein the transaction message is an 
Intelligent Network Application Part (INAP) message. 
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